前言
在 Day 12 與 Day 13 中，我們分別解析了 MedicationRequest 處方資料結構，並以狀態機概念實作了條碼給藥核對引擎 BcmaVerificationEngine。現在，我們要將這套臨床安全防護邏輯正式接上 Express 後端，打造完整的給藥核對與執行 API。

在病房給藥流程中，點下「確認給藥」並不是單純把狀態標為 completed，而是需要滿足三項嚴格的系統需求：

原子性核對與狀態流轉（ACID）： 在同一個資料庫 Transaction 內，驗證條碼、更新排程狀態為已給藥，並寫入給藥執行日誌。

防重複給藥（Double Administration Protection）： 透過資料庫行級鎖（FOR UPDATE）防止兩位護理師或重複點擊造成同一劑次被重複扣帳與施打。

產出合規的 FHIR Resource： 生成符合 HL7 FHIR 規範的 MedicationAdministration 資源，完整記錄誰在何時、依據哪張處方、施打了何種劑量。

一、給藥 API 資料流與交易邊界
當護理師在床邊 PDA 依序掃描病患手圈與藥品包裝後，前端會發送包含條碼、劑量與當前時間的請求至後端：
二、內部資料庫綱要與關聯設計
在 Day 10 的 PostgreSQL 基礎上，我們定義給藥排程明細與執行軌跡資料表：
三、實作 FHIR MedicationAdministration 轉接器
建立 src/adapters/fhir-medication-admin.adapter.ts，負責將執行成功的資料轉換為標準 FHIR 格式：
四、核心業務邏輯：防重核對與 Transaction 實作
建立 src/services/medication.service.ts。重點在於使用 FOR UPDATE 鎖定排程紀錄，並透過 Day 13 的 BcmaVerificationEngine 執行防錯比對：
五、Express Controller 與實機驗證
建立 API 端點 POST /api/v1/clinical/medications/administer：
cURL 測試演練
正常核對通過請求：
伺服器回應（200 OK）：

若立即重複發送相同請求：
-伺服器狀態碼立即回傳 409 Conflict。
-錯誤訊息提示：衝突：該劑次藥物已經完成給藥，嚴禁重複施打！，成功擋下重複用藥風險。

小結
今天我們完成了臨床閉環中最具指標性的一道關卡：
1.透過 PostgreSQL 資料庫 FOR UPDATE 行級鎖 與 Transaction，徹底防堵並行請求導致的重複給藥。
2.完整鏈結了 BCMA 檢核邏輯與執行流程，在伺服器端確保人、藥、量、途徑、時間五對原則。
3.實作轉接適配器，產生標準合規的 MedicationAdministration Resource，為跨系統用藥履歷追蹤奠定基礎。現在後端的核心業務邏輯已經相當完整，

明天 Day 20 我們將聚焦在醫療資料的品質防護：醫療資料檢核——使用 FHIR Validator 確保產出的 Resource 嚴格符合標準與 Profile 規範！